In the field of printing, it is generally desirable to maximize printing quality and printing speed at a printer. Customers tend to dislike any delay that occurs between sending a print job to a printer and receiving the printed sheets of the print job. Therefore, printer manufacturers strive to optimize both the physical printing speed of marking engines that mark printed sheets and the processing speed of devices that prepare incoming print jobs for printing by interpreting and rasterizing them.
In order to increase the processing speed for incoming print data, print controllers often include multiple Raster Image Processors (RIPs) that operate in parallel. The print controller splits the incoming print job into segments of data (e.g., logical pages), and sends the segments to the parallel RIPs for interpretation and rasterization. For example, each of the parallel RIPs may interpret incoming segments by generating a display list or other instructions for marking pels on a page. The parallel RIPs may further rasterize/render the segment by placing pels in a bitmap image with an appropriate mark/color based upon the generated display list.
Processing incoming print data using parallel RIPs is generally desirable because it increases the speed at which a print job may be interpreted and rasterized, which is often the most time consuming part of printing an incoming job. Unfortunately, segmenting a print job encoded according to a page description language (e.g., PostScript) into individual logical pages may result in undesirable performance issues. Reliably segmenting the print job typically requires utilizing a pre-RIP interpretation step, wherein the entire print job is pre-processed and interpreted by a serial processor. The print job is then segmented into logical pages based upon the interpreted print data. Interpretation is generally faster than rasterization/rendering, but still requires significant processing resources. As such, adding serial interpretation as a necessary pre-processing step results in a significant loss of performance because it creates a serial bottleneck for the parallel processing that occurs later on. Thus, serial interpretation and pre-processing is not preferred because it limits the speed at which print data is provided for parallel RIP processing.
An alternative method involves finding comments within the print data that are used to indicate a page boundary (e.g., Document Structuring Convention (DSC) comments), and splitting the print job into segments based upon these comments. This technique is generally much faster than serial pre-processing of the print job because it is not necessary to interpret the print data in order to detect page boundaries. However, this method relies upon the integrity of the application that first generated the print job (an external source over which a print controller has no control). If the application was not properly designed, it might not include a comment to mark each and every page boundary in the print job. Unfortunately, if the print job is improperly segmented, page-level instructions for the print job (e.g., watermarks, footers, etc. defined in a job ticket) will be applied to the wrong segments of print data. Thus, a parallel RIP that encounters a multi-page segment for processing is likely to generate invalid rasterized print data for the job.
In the present state of the art, a print controller detecting such a segmenting error from a parallel RIP will abort the print job in order to prevent the generation of bad print data, and will indicate to the host that the print job contains an error. Thus, only a portion of the print job will be printed (i.e., the pages of the print job that occur after the error will not be printed). This is generally undesirable to the end user, because the end user may not be capable of generating a print job that has a comment indicating each page boundary. Even assuming that the print job can be recreated in such a manner, regenerating the print job creates a significant and undesirable delay in the printing process.